微服務常見的兩個協議：gRPC 和 GraphQL

在開始 Coding 之前，先來介紹一下微服務中常見的兩個協議：gRPC 和 GraphQL。

gRPC 介紹

以往在單體架構（Monolith）服務時，內部基本上沒有什麼溝通成本。然而，當我們把一個服務拆分成多個微服務後，如何有效降低微服務之間的溝通成本成為了一個很重要的議題。你可以想像，當你在微服務外部呼叫一個 publish order 的請求時，order service 可能還需要尋找 product、warehouse、shipping、user 和 payment 等微服務來確認這個訂單是否合法並確認狀態。如果你內部仍然使用笨重的 REST API，效能會變得非常糟糕。因此，我們通常需要尋找一種更輕便且快速的通訊方式來取代傳統的 HTTP。

gRPC 是 Google 開發的一種高效能通訊框架，主要用於分散式系統間的數據交換。它基於 HTTP/2 協議，並使用 Protocol Buffers（protobuf）進行數據序列化，這使得數據傳輸更快且占用更少的資源。相較於傳統的 HTTP API，gRPC 更適合高效能應用，因為它支援多路復用和雙向通訊，使得客戶端和服務端可以多路發送請求並同時傳輸數據。protobuf 格式比 JSON 更輕量，傳輸速度快且佔用帶寬更少。

gRPC 與 HTTP 的不同之處

1. gRPC 使用 HTTP/2，而 HTTP 使用 HTTP/1.1。
2. gRPC 傳輸二進制格式，HTTP REST 常用 JSON。
3. gRPC 支援雙向通訊，HTTP REST 是請求-響應模式。

gRPC 的優勢在於高效能和多語言支援，但學習成本較高，適合內部微服務通訊。由於支援 Stream，gRPC 也常被用於大數據分析、影像處理、遊戲通訊等場景。不過，gRPC 的主要缺點是內容不易被直觀讀懂，且在網頁瀏覽器中的應用有限，因為大多數瀏覽器對 HTTP/2 和 protobuf 的支援還不夠完整。

你可以試著在網上搜尋 REST 與 gRPC 的效能比較，會發現 gRPC 的效能大幅超越 RESTful API。


gRPC vs REST speed comparison (shiftasia.com)

GraphQL 介紹

GraphQL 是由 Facebook 開發的一種查詢語言，用於 API 通訊。它提供了一種靈活且高效的方式，使客戶端能夠向服務端請求數據並只返回需要的部分。GraphQL 通常應用於 REST API 之上，能有效減少過多或過少的數據傳輸。

相較於傳統的 REST API，GraphQL 更靈活，因為客戶端可以指定具體所需的數據結構，從而減少多次請求與額外數據的傳輸。同時，GraphQL 的單一端點設計簡化了多個資源的請求流程。

GraphQL 與 REST API 的不同之處

1. GraphQL 使用單一端點來處理所有請求，而 REST API 通常有多個端點。
2. GraphQL 客戶端可以查詢所需的特定數據，REST API 通常返回預定義的完整數據結構。
3. GraphQL 支援複雜查詢和多層關聯數據請求，而 REST API 通常需要多次請求來獲取多層級數據。

GraphQL 的優勢在於靈活的數據請求與減少不必要的數據傳輸，特別適合前端開發以及數據需求多變的應用場景。此外，它擁有良好的工具和生態系統支援，如自動生成 API 文檔與內建的數據驗證。不過，GraphQL 的學習曲線相對較高，對於簡單的應用來說，REST API 仍是一個更易於實現的選擇。

你可以到 GraphQL Playground 測試以下的查詢，這能讓你更好地理解 GraphQL 的運作。你會發現，通常 GraphQL 只需要一個單一的端點，而可以通過不同的查詢取得不同的數據。

一個端點取得不同 Entity Data

自由增加或減少 Properties

使用 Filters 來篩選資料

結語

介紹完 gRPC 和 GraphQL 之後，下一章節我們將開始規劃系統架構。